今天要完成什麼

Weekly Review 將一週的任務、行程與郵件活動整理成可 review 的專案報告。它展示週期 scheduler、跨服務讀取、風險摘要與 Docs 寫入核准。

報告不是把資料堆在一起，而是回答：完成了什麼、延期什麼、有哪些風險、下週前三項優先工作是什麼。

實作

建立 weekly ScheduledJob，每週五下午觸發 weekly-review。Agent 讀取本週完成與未完成 tasks、Calendar 事件及指定 project query 的郵件摘要，再輸出 Markdown 預覽：

# 專案週報
## 本週完成
## 延期與原因
## 風險／待決策
## 下週優先事項

預覽先送到聊天。使用者核准 docs.create 後才建立 Google Doc，並回傳 URL。若拒絕，仍可在聊天中修改文字後重新提出。

動手試試看

建立一週測試資料：三筆 done、一筆 overdue、一筆 waiting，以及兩場專案會議。郵件只放一封帶明確風險的測試內容。手動執行 weekly skill，確認報告的完成、延期、風險與下週四區都有來源。

特別檢查延期原因：資料只寫「尚未完成」時，報告必須標示「原因未提供」，不能讓 Gemini 補成「資源不足」。風險也要區分文件明確陳述與模型推論。

聊天預覽後先要求修改一個措辭，再核准建立 Docs。打開文件確認段落結構與聊天版本一致；Jobs runAt 增加七天。拒絕路徑則不應在 Drive 產生半成品。

驗證

準備包含 done、waiting、overdue 的任務資料，確認分類正確。沒有證據的延期原因不得由模型編造，應顯示「未提供」。

核准前 Drive 不應出現文件；核准後文件標題、段落與 URL 正確。weekly job 執行後 runAt 增加七天。

發布素材

• 聊天 Demo：週五彙整完成、延期、風險與下週優先事項並建立 Docs。
• 設計焦點：每一段結論都能追溯 Tasks、Calendar 或 Gmail 證據。
• 測試／失敗案例：資料不足時保留 unknown，不製造樂觀進度。
• 當日 Git tag：day-26。下一篇完善聊天核准。

安全與限制

週報可能把多個來源的敏感內容集中，風險反而比單一資料高。預覽與文件都要控制細節，不放完整郵件或私人活動。

第一版沒有成效統計圖表與多人簽核；它的目標是個人 review。下一篇深入核准狀態與重放攻擊。

週報可用三個 KPI 評估：已完成任務召回率、無證據陳述數量、人工修改時間。好週報不是字多，而是可追溯、少修改、能幫使用者做下週決策。

可發布成果

本篇附上虛構專案的一週資料與預期週報，讓讀者能重跑。Release 中同時提供 skill 宣告、測試資料與 Docs 輸出範例。文章不能只說「AI 幫我寫完」，而要標示每個段落使用了 Tasks、Calendar 或 Gmail 的哪一項證據。

若人工修改時間沒有下降，就應回頭調整資料結構與 skill 指令，而不是換更大的模型。這也是 Build on Google AI 專案管理題目最能展示實務價值的評估方式。